METHOD AND DEVICE FOR COLLECTING AND REPORTING DATA 



CROSS-REFERENCE TO RELATED APPLICATIONS 
This application claims priority from US provisional application 60/409,779, filed on 
5 September 10, 2002, the contents of which are expressly incorporated herein by reference. 



TECHNICAL FIELD 
This disclosure relates to data collection and reporting, and, more specifically, relates 
to collecting data from gaming devices having multiple games and capable of having multiple 
10 denominations of wagers, as well as reporting the collected data. 



BACKGROUND OF THE INVENTION 
Networked slot machines capture large amounts of data, such as amount of money 
deposited into the machine (coin-in), amount paid by the machine (coin-out), amount of 
15 jackpots, and bonuses, etc. While older slot machines were single purpose, i.e., they were 

limited to a single type of game, newer slot machines are capable of playing different types of 
games, even within the same cabinets. For example, the same game cabinet can hold a slot, 
poker, and a keno game. Additionally, some of these newer games also have more than one 
betting denomination, i.e., minimum price per play. The denomination could be set by the 
20 casino, for instance to offer discounts at slower play times, or could be set by the player, if, 
for instance, different denominations had different pay tables. These type of machines are 
sometimes referred to as MGMD (Multi-Game;Multi-denomiation) devices. 

Each possible combination of denomination, game type, and game pay schedule may 
result in a unique theoretical hold percentage. Each combination may also have differing 
25 levels of player acceptance. 

To determine player acceptance and other information, a casino operator must be able 
to collect data from the slot machines and perform queries on the data. Present game 
accounting systems are unable to account for MGMD devices. 

Embodiments of the invention address these and other deficiencies in the prior art. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 
The description may be best understood by reading the disclosure with reference to 
the accompanying drawings. 
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FIG. 1 is a functional block diagram of a gaming network on which the data collection 
system operates. 

FIG. 2 is a functional block diagram of the organization of a data collection system 
according embodiments of the invention. 
5 FIGs 3 - 18 are example screen views illustrating example screens that can be used to 

configure the accounting system according to embodiments of the invention. 

FIGs 19-23 are example reports that can be produced by embodiments of the 
invention. 



10 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Embodiments of the invention are directed to a slot machine data collection and 
reporting system capable of operating with multi-denomination, multi-game machines. These 
machines allow the patron to select the denomination of the wager unit, the game type, and 
the exact game pay schedule to be played. For example, the patron could configure the 

15 machine to have a base wager unit of a quarter, to play a five-card draw poker game, and to 
have a specific pay schedule that pays special bonus pays on certain four-of-a-kind hands. 

Each possible combination of denomination, game type, and game pay schedule may 
result in a unique theoretical hold percentage. Each combination may also have differing 
levels of player acceptance. For this reason, a system that allows for the computation and 

20 tracking of handle, game hold percentage, theoretical hold percentage, and net win for each 
of the possible combinations within a single slot machine cabinet is very useful. 

The system can provide the following information in reports on a weekly, month-to- 
date, and year-to-date basis for each game, schedule, and denomination on a multi- 
denominational and multi-game machine: slot handle, slot win, individual game hold 

25 percentage, machine hold percentage, and actual game hold and machine hold percentage. Of 
course, with the data collected by the system, other reports are available as well. 

The system can be used as a data analysis and management tool, but typically would 
not be used to report or auditing taxable revenue, although it would be possible to do so. As 
such, the system can be used in conjunction with and augments existing Slot Accounting 

30 systems. All existing Slot Accounting related functionality is maintained. 

The system can operate on game network hardware, for instance a game network as 
described with reference to FIG. 1 , which is an example of a modern gaming network. FIG. 
1 is identical to FIG. 1 of US Bl 6,245,483, assigned to the assignee of the present invention, 
the teachings of which are incorporated herein in their entirety. In FIG. 1, indicated generally 
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at 10 is a block diagram illustrating electronic gaming machines (EGMs), like EGMs 12, 14, 
which are interconnected by a computer network. Shown in the gaming network 10 are three 
banks of EGMs, indicated generally at 16, 18, and 20. Each separate EGM is connected via a 
network connection, like connection 22, to a bank controller 24. In embodiments of the 

5 invention, each bank controller 24 includes a processor that facilitates data communication 
between the EGMs in its associated bank and the other components on the network. The 
bank controller 24 also includes audio capabilities, like a CD or DVD ROM drive coupled to 
an audio board or sound card for transmitting digitized sound effects, such as music and the 
like, to a speaker 26 responsive to commands issued over the network 10 to bank controller. 

10 The bank controller 24 is also connected to an electronic sign or screen 28 that displays 
information, such as scrolling, flashing, or other types of messages that indicate jackpot 
amounts and the like, which are visible to players of machines on bank 16. These message 
displays 28 are generated and changed responsive to commands issued over the network 10 to 
the bank controller 24. Each of the other banks 18, 20 of EGMs include associated bank 

15 controllers, speakers, and signs as shown, which operate in substantially the same manner. 
Additionally, sound and visual displays can be mounted directly on one or more of the EGMs 
12, 14 directly. 

A network connector, such as an Ethernet hub 30 connects the bank controllers 24 
associated with banks 16, 18, 20 of EGMs to a concentrator 32. Another Ethernet hub 34 

20 connects similar bank controllers (not shown), each associated with an additional bank of 
EGMs (also not shown), to the concentrator 32. The concentrator 32 functions as a data 
control switch to route data from each of the banks to a translator 36. The translator 36 
includes a compatibility buffer between the concentrator 32 and an accounting system 38. 
The translator 36 functions to place all the data gathered from each of the bank controllers 

25 into a format compatible with an accounting system 38, which is coupled to an accounting 
database 37. The accounting system 38 could be implemented by a microcomputer including 
a microprocessor and operating system, such as an Intel Pentium microprocessor running one 
of the Microsoft Windows systems. Events that occur on each of the EGMs are monitored by 
the EGM and some events and totals may be stored in meters on the EGMs. Portions of the 

30 system communicate with an interface to the EGMs to retrieve data from the EGM and 

temporarily store it on the accounting system 38. Once on the accounting system, the data 
can be tabulated, queried, totaled, modified, formatted, and presented as described herein. 
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Another Ethernet hub 39 is connected to a configuration workstation 40, a player 
server 42, and to bonus servers 44, 46. Hub 39 facilitates data flow to or from workstation 40 
and servers 42, 44, 46. 

The configuration workstation 40 has a user interface that allows portions of the 
5 network 10 and the servers 42, 44, 46 to be set up and modified. The configuration 
workstation 40 could include a personal computer having a keyboard, monitor, 
microprocessor, memory, an operating system, and a network card coupled to the Ethernet 
hub 39. 

The player server 42 includes a microcomputer that is used to track data of players 
10 using the EGMs. Another function of the player server 42 is to control messages that appear 
on displays associated with each EGM. The player server 42 may be embodied in a 
microcomputer including, for instance an Intel Pentium Processor, Microsoft operating 
system and a network card to couple the server to the Ethernet hub 39. 

Bonus servers 44, 46 each are embodied by a microcomputer and are used to control 
15 bonus applications or bonus systems on the gaming network 10. Each bonus system includes 
a set of rules for awarding jackpots in excess of those established by the winning pay tables 
of each EGM. Some bonus awards may be made randomly, while others may be made to 
link to groups of EGMs operating in a progressive jackpot mode. Examples of such bonuses 
and networks used to implement them include those as described in US patents 6,319,125 and 
20 5,655,961, both of which are assigned to the assignee of the present invention, and the 
teachings of both of which are incorporated herein in their entirety for all purposes. 

In some embodiments of the invention, due to a desire to minimize any changes in 
game-to-system protocols, IGT's SAS protocols can be used. 



25 Definitions: 

For clarity, common terms in this description will be defined according to the 

definitions below: 

"Game" refers to the particular game type and model, for example: 

Standard Draw Poker 
30 Double-Double Bonus Poker 

Deuces Wild Poker 
Reel-em-In Video Slot 
Austin Powers™ Video Slot 
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"Program" refers to the award schedule/game outcome probabilities that define a 
particular version of a model that yields a specified payback. Generally, game manufacturers 
assign unique numbers to each "program". This is a player selectable element in a machine 
allowing the player to changes the schedule or model for payout. This will be referred to as 
5 Schedule. 

"Denomination" refers to the unit of wagering. In this context, denomination is not 
the denomination of the coin in the hopper or coin comparator. 

"Slot handle" refers to the total dollars wagered on a specific 
denomination/game/program combination (DPC). This will be referred to as DPC Handle. 
10 "Slot win" is the total dollars "held" or won by a specific DPC. This will be referred 

to as DPC Win. 

"Individual game hold percentage" is the manufacturer specified theoretical hold 
percentage for that DPC. This will be referred to as DPC theoretical hold. 

"Machine hold percentage" is the computed theoretical hold percentage for the 
15 cabinet taken as a whole, given an actual distribution of play across all DPCs in the cabinet. 
This is computed by taking the handle-weighted average of the theoretical holds of all DPCs. 
This will be referred to as Cabinet Theoretical Hold Percentage. 

"Actual game hold percentage" refers to the observed hold percentage for a specific 
DPC. Because players can insert coins or bills while in one DPC and then change to other 
20 DPCs, the term "actual" must be carefully defined. Typically, actual refers to a game 

performance statistic based on an actual count of bills, coins, and jackpot/fill slips. Since 
players are free to select DPCs after a bill is inserted, there is no way to know which bill or 
coin is associated with each DPC. Therefore, the traditional meaning of actual does not apply 
here. For the sake of clarity the term actual will be eliminated and "game hold percentage" 
25 will be defined as: 

((total dollars wagered in a DPC - total of all dollars paid out in all forms by a DPC)) 
/ (total dollars wagered in a DPC) 

Since actual values don't apply, metered amounts will be used for all values in the 
above expression. This will be referred to as DPC hold percentage. 
30 "Machine Hold Percentage" refers to the observed hold percentage of the entire 

cabinet. It is defined as: 

(total dollars wagered in a cabinet - total of all dollars paid out in all forms by a 
cabinet) / (total dollars wagered in all DPCs of the cabinet) 
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To keep this definition analogous to the definition of game hold percentage, metered 
amounts will be used in all values in the above expression. This will be referred to as the 
Cabinet Hold Percentage, 

5 Embodiments of the invention are capable of computing the following information: 

DPC Handle 
DPC Win 
DPC Hold 

DPC Theoretical Hold 
1 0 Cabinet Theoretical Hold 

Cabinet Hold 
and others. 

FIG. 2 illustrates a sample configuration how MGMD accounting information is 
15 organized. In FIG. 2, two machines of identical type, ID1, are illustrated. The machines 

have the reference numbers 10001 and 10002, respectively. The machine type ID1 is further 
configured with configuration ID 1 , loosely broken into two sections, the denomination 
section and a paytable section. The denomination section has a group identification of ID1, 
which, as illustrated in FIG. 2 includes three denominations, $.25, $.50, and $1.00. 
20 Instructions of how to create and modify denomination groups are given below. The paytable 
section is also set up as ID1, to which several games are ascribed. Each separate combination 
of game, denomination, and paytable is referred to as a unique DPC. 

With reference back to FIG. 1, an MGMD server 60 runs an MGMD accounting 
application that connects to the accounting database 37. Of course, as used herein, the 
25 accounting database is used generally and refers to any data that is possible to be stored in a 
casino environment. Additionally, the accounting system 38 and the accounting database 37 
may in fact be spread across multiple physical computers, servers, and data storage devices. 

Machine Configuration, Enrollment, and Changes 

The specific machine pay table information may not be available to the system 

30 automatically until a game session. As a result of this, machine DPCs can be setup manually 
by the analyst using an external application. The MGMD application captures all additions, 
deletions and changes to the DPCs and transfers this to the accounting database 37. The DPC 
information stored in the database should be of sufficient detail to allow the operator to 
assign and enter the corresponding theoretical hold percentage obtained from game 

35 manufacturer literature. The tracking of this information in the database should include start 
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dates, end dates and change dates for the configuration. It is possible for the casino to not 
setup the machine information manually and simply wait for game play to occur for each of 
the pay tables. If possible, the application based configuration information should contain: 
For each DPC: 

5 Schedule number (in sufficient detail to allow the operator to determine a 

theoretical hold percentage from the game manufacturer support documentation) 
Denomination 
Maximum Bet 
Progressive levels 

For each Cabinet 

EPROM or Program ID version (associated with pay table) 

From the perspective of the interface to the EGM 12, 14, a serial machine interface 
board, or SMIB, an example of which is a Bonus Engine 2 (BE2) sold by Acres Gaming of 
Las Vegas, Nevada, and from the perspective of ABS (Acres' Bonusing System, also 
available from Acres Gaming), this is at least one sub-game on an EGM. It is possible for 
more that one game to be the same program ID, but from a data-gathering perspective, this is 
one game. 

One program ID could be associated with different types of games. A Keno pay table 
may cover several different versions of Keno but the games will all be Keno. There would 
not be any video reels or poker games on that program ID. However, that same game can be 
configured to have different hold percentages at different denominations and therefore have 
different program ID identifiers for different denominations. 

Part of the data that the BE2 can collect and send up to the accounting database 37 for 
each program ID can include fields that identify the game, paytable, and an additional id. 
These three fields can be concatenated together to generate a game identification number, 
which can be further related to a name that the slot manager can easily recognize. 

With reference to FIG. 3, illustrated is a software setup screen for the MGMD 
accounting application according to an embodiment of the invention. Through this console 
screen, modifications to paytables, paytable groups, denominations, denomination groups, 
configurations and machine setup can be accomplished, as described below. 

Paytables and paytable groups 
35 An EGM sends game and sub-game descriptions to the accounting system 38, where 

they can be obtained and used by the MGMD server 60. The game and sub-game description 
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indicates the game type and pay table (glass). The addition of a numeric code, such as 4/5/6 
means it pays 4 for straight, 5 for flush, and 6 for full house. 

As shown in FIG. 4, various paytables that have been set up are illustrated. An 
example paytable entry could be double double bonus 4/5/6 (BSN DD 4/5/6), associated with 

5 a particular ID and additional ID. Paytables can be added, deleted, and modified using a 
screen such as that illustrated on FIG. 5, running on the application. 

Some game operators adjust payout values from particular types of games, such as 
poker. Embodiments of the invention can accommodate these variations by adding the 
desired adjustment value to the Coin-in * Theoretical percentage. This calculation could be 

10 made part of the paytable setup, where a user can indicate an additional percentage to be 
added, for instance. Also, the Cabinet hold could be output to the screen for the user. 

A typical paytable ID is six digits length. Any digits in a paytable ID above six can 
be used to indicate an "additional" ID. Thus, a paytable ID 003455 has a paytable ID and no 
additional ID, a paytable ID 0234556 has a paytable ID of 023455 and an additional ID of 6, 

15 and a paytable ID 123455456 has a paytable ID of 123455 and an additional ID of 456. 

Once setup, paytables can be grouped according to how they are seen in the game. 
Example groups are illustrated in FIG. 6, which can be added, deleted, and modified by the 
screen illustrated in FIG. 7. Once grouped, the paytables can be applied to a configuration, 
which is then tied to a machine type, as illustrated in FIG. 2. 

20 Paytables are populated by meter values from the EGM 12, 14 (FIG. 1). More 

specifically, the BE2 mounted within an EGM 12, 14, communicates with game electronics 
within the EGM 12, 14. When each paytable on the game is played, the BE2 sends the game 
session meters to the MGMD system. The meters are stored, and any paytable information is 
written to files. Paytable information can be setup before hand manually by users, as well as 

25 through the user application. 

Denominations and Denomination Groups 

Denominations can be added/deleted/modified by using a screen such as that shown in 
FIG. 8. Once configured, the different denominations are shown on the denomination screen 
30 as shown in FIG. 9. Denominations can also be grouped, by using a screen such as that 

shown in FIG. 10. Once grouped, the denomination groupings appear in the main screen, as 
illustrated in FIG. 1 1 . An example denomination grouping is also illustrated in FIG. 2. 

Other configurations 
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Once the paytables, denominations, and their associated groups are defined, a 
configuration identification group is defined, for instance by using the screen as illustrated in 
FIG. 12. For example, a casino analyst may want to review data based on various cabinet 
configurations. As an illustration, an analyst may want to compare Game Kings that run 
Configuration 1 to Game Kings that run Configuration 2, where the configurations are as 
illustrated in Table 1 , below: 



Configuration Platform 



Table 1 
Sub-Game desk. 



Display type Denom 



1 



Game King DD Bonus 4/5/6 Poker 

Dbl Bonus Poker 
Deuces Wild Poker 



.25/.50/1.00 



Game King DD Bonus 4/5/6 Poker 

Dbl Bonus Poker 



.25/.50/1.00 



Because some configurations can have denominations that are only available to 
specific sub-games on a machine, an "Advanced" button on the screen illustrated in FIG. 12 
is provided. Clicking such a button brings up an advanced screen, such as that illustrated in 
FIG. 13. 

Once setup, the configurations appear such as in the example screen illustrated in 
FIG. 14. 

Also as illustrated in FIG. 2, once paytables and denominations are setup, they are 
grouped according to how they are seen in a game. This can be accomplished through a 
system maintenance paytable and denomination grouping. Once paytables and 
denominations are grouped, they can be applied to a configuration, as described above. The 
configuration is then tied to a machine type, by navigating through the screens illustrated as 
FIGs 15, 16, and 17 

Running the accounting application 

Once properly set up, accounting data is gathered from the EGMs 12, 14 (FIG. 1), and 
populates the accounting database 37. The collection and transmission of data does not 
impact system performance in other areas. System response to jackpots, fills, bonus pays, 
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player card inserts, and electronic funds transfers, etc. are not adversely affected by the 
addition of messaging required to support multi-denomination/multi-game reporting. 

In some embodiments, the meter collection takes place on a daily basis. Meters that 
have changed are collected at rollover (a predetermined time set in the system such as every 

5 15 or 30 minutes) and at DG change, such as when a player completes a particular gaming 
session, and changes the denomination or game he or she is playing (denom or game change 
after the session is complete). Processing time and network traffic is assessed. To ensure 
performance standards, in some embodiments of the invention, only the meter or meters that 
have changed, rather than the entire meter packet, is collected. Also, in some embodiments 

10 of the invention, only a subset of all the available meters is sent to the accounting system 38. 
Additionally, rollover meters are within acceptable accuracy levels for EOD (end of day), 
because these meters are within a 7-15 minute window of the EOD. All changes in meters 
for a game session in progress prior to EOD are be reported for the next business day if the 
session ends within this 7-15 minute window of the EOD. 

15 The issue of blown meters can be handled by several different methods. Generally, 

the sub-game meters must equal the cabinet meters. In some embodiments, sub-game meters 
within +/-4% of the total game meters are accepted. This number can be adjusted, for 
example, by using an interface screen such as that illustrated in FIG. 18. If sub-game meters 
are found to be out of variance, a three-day average is used to fix meters. It is acceptable to 

20 use only audited meters for reports. If the Coin In, Coin Out, or any of the jackpot and bonus 
related meters are modified during the accounting audit, these audited meters should be 
reflected back to the Multi-denom multi-game meter table. At the cabinet level, when the 
system user reviews reports that come out of the Multi Denom Multi Game module, 
(described below) they trace back to the Coin In, Coin Out and JP Payouts on the Meter Slot 

25 Win reports. 

Specific Meters 

Information can be derived from the following meters: 

- Coin In: Total pennies wagered in a DPC. 

- Total Coin Out: Total pennies paid as a result of a winning outcome generated by 
30 the DPC. It would include pennies paid on progressive jackpots, since these are machine 

determined. It would not include pennies paid as the result of system bonus payments such 
as XTRA CREDIT, or Lucky Coin awards. 
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Based on these definitions, the desired machine performance metrics can be computed 
over a specific time period as follows: 

( 1 ) DPC handle = ACoin In 

where: ACoin In = Ending Coin In Meter - Starting Coin In Meter 

(2) DPC Win = DPC handle - ACoin Out 

where: ACoin Out = Ending Coin Out Meter - Starting Coin Out Meter 

(3) DPC Hold Percentage = DPC Win I DPC Handle * 1 00 

(4) Cabinet Hold Percentage = 1LDPC Win I ZDPC Handle * 100 
where: T,DPC Win = Sum of win from all DPCs in a cabinet 

1LDPC Handle = Sum of handle from all DPCs in a cabinet 

(5) Cabinet Theoretical Hold Percentage = 

100 * Z(Z)PC Handle I Cabinet Handle * DPC Theoretical Hold) 
where: Z is the summation over all DPCs in a cabinet 
Cabinet Handle = total handle for the cabinet 

Since, during the audit process, it may be advantageous to know how much of total 
coin out was paid in hand pays versus machine pays, in some embodiments of the invention 
the Total Coin Meter is split into two constituent parts. This may also allow compliance with 
soon to be released slot accounting standards. These two parts are: 

- Coin Out: Total pennies paid directly by the machine as the result of a winning 
outcome generated by a DPC. This would include pennies paid directly by the machine in 
the form of credits to the credit meter, coins from the hopper, an electronic funds transfer, or 
a ticket out. This would not include payments made at the machine by an attendant. This 
would not include system generated bonus payments such as LUCKY COIN jackpots or 
XTRA CREDIT. 

- Hand Pay Out: Total pennies paid as a result of a winning outcome generated by a 
DPC that were paid by an attendant in the form of a hand pay. This does not include system 
generated bonus payments paid by hand such as lucky coin jackpots. 

Given these definitions Total Coin Out can be expressed as: 
Total Coin Out = Coin Out + Hand Pay Out 
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Coin Out Includes, for example: Game Win from the credit meter; Cancel Credits, 
Bonus Pays, XTRA CREDIT, low level Progressives, Mysteries and Lucky Coin. 

Handpay Out Includes, for example: Handpays, High Level Progressives; Jackpots 
where the game was actually locked up with a JP signal. 



Meters Summarized 



The following meters are collected currently by the gaming system and stored on the 
accounting server 38 (FIG. 1) in the Accounting database 37 in a meter table. The collection 
of the meters can be associated back to a unique identifier, which most likely will be the 
combination of Game ID, Wager Denomination, and Pay Table ID in play at the time the 
meters moved. 

Value of physical tokens inserted; 
Value of physical tokens paid out by the game; 
Value of wagers; 

Value of winnings delivered by the game; 
Number of game cycles played; 

Value of winnings delivered by attendant by a Handpay; 
Value of winnings that were first paid to a game credit meter 
but later delivered to the player by a Handpay caused when the 
player attempted to cash out; 

Value of winnings from participation in a Linked Progressive; 
Value of bonus awards delivered as a match of a play wager 
(such as XTRA CREDIT); 
Value of deductible bonus awards paid; 
Value of nondeductible bonus awards paid. 



MtrTrueCoinln - 
MtrTrueCoinOut 
MtrCoinln- 
MtrCoinOut- 
MtrGames - 
Mtr JP - 

MtrCreditPay - 



MtrProg - 
MtrMatchBonus - 

MtrCOdBonus - 
MtrCOndBonus - 



Bonusing Considerations 

The definitions and calculations given above include bonusing payments. This 

ensures that the effects of bonusing do not taint the analysis of DPC performance. This 

allows DPC hold to be compared to theoretical DPC hold, prior to consideration of bonus 

payments. 

To evaluate the impact of bonusing two additional bonusing meters are used. 
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- Deductible Bonus Paid Meter- Increments once for every penny paid as a bonus that 
is considered to be deductible from machine win in the calculation of taxable machine 
revenue. 

- Non-Deductible Bonus Paid Meter- Increments once for every penny paid as a 

5 bonus that is not considered to be deductible from machine win in the calculation of taxable 
machine revenue 

Provided sufficient bandwidth is available, these meters should also be maintained for 
each DPC. 

Data Collection Frequency 

10 Meter data should be gathered upon game play and at time rollover, such as every 1 5 

or 30 minutes, for example. In some embodiments of the invention, for end of day, if meters 
are collected within 15 minutes of the hour, the statistical impact is felt to be minimal at this 
time and deemed acceptable. At time rollover the player's current session may be sent. It is 
understood that a player's session may span more than one business day. Meters for the 

15 player's session is recorded as close to the day they occurred as possible resulting in the most 
minimal statistical impact. 

Data sets from each machine should preferably be gathered at the same time. In other 
words, it is not preferred to gather meters from one DPC during one hour, then from another 
DPC another hour later, etc. Meters from all DPCs within a cabinet should be gathered at the 

20 same time. If possible, rollover DPC meters should be gathered in a manner that allows them 
to be time coincident with the existing meter set used for Slot Accounting. This allows for 
comparisons between systems. 

Slot Accounting Database Modifications 

The Slot Accounting database 37 (FIG. 1) accommodates the new tracking fields and 
25 calculation results described in the above sections. Data would be written at least once a day 
to the database and summarized by MTD, YTD and LTD. As stated above, the machine may 
be considered the "master" storage area for the DPC configurations. 

Data Storage 

Below is a summary of data that can be colleted from the EGMs, through the BE2s, or 
30 computed from data collected from the EGMs, and stored either on the accounting server 38 
(FIG. 1), the accounting database 37, or elsewhere in the game network.: 
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- A ctual Hold Per Game 

- Cabinet Handle 

- Cabinet Hold 

- Cabinet Theo Hold 

5 - Deductible Bonus Paid Meter 

- Denom(Wager) 
-DPC handle 
-DPC Hold 

- DPC Theo Hold 
10 -DPC win 

- EPROM 

- Game ID 

- GameType 

- Maximum Bet 

15 - Meter Hand pay Out (defined as winning outcome generated by the DPC and 

paid by attendant) 

- Metered Coin In 

- Metered Coin Out (defined as winning outcome generated by the DPC and 
paid by machine) 

20 - Metered Days 

- Non-Deductible Bonus Paid Meter 

- Pay Table ID and Additional Pay Table ID, if needed 

- Progressive Levels 

- Schedule Number 

25 - Total Coin Meter (meter coin out + meter hand pay out) 

Hold values are typically expressed as percentages. 

It terms of program, or EPROM number, i.e. the specific version of EPROM(s) in the 
slot machine, the casino customer should be capable of setting up a unique machine type 
30 based solely on a difference in EPROM number. 

For example, if the location wants to track an IGT S+ Double Diamonds with main 
game EPROM Version 1 .0, separately from an IGT S+ Double Diamonds with main game 
EPROM Version 2.0, then they can do that by setting up a unique machine type for each of 
these configurations in their database. 
35 Presumably, these types would also be used in the database. It would also be 

advantageous for the machine to report the EPROM number(s) to the database, which can be 
done using modern communication protocols. 

Schedule refers to any unique model/schedule configuration, which the player can 
select. This could be as simple as changing from 5/8 Draw Poker to a 7/10 Double Double 
40 Poker. A player could also change from 5/8 Poker to Wild Rhino video slot; this would be a 
change of model and pay schedule, and would result in a separate DPC. 
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Implementation considerations 

A DG change event is when the player selects "a new game" or "new denomination 
for a given game" and the game is played. When this happens the BE2 within the EGM can 
send the meter data (either only the meters that have changed, or only a subset of the 

5 available meters in the EGM, or a combination of the two) to the accounting system 38, and 
by extension, to the MGMD server 60. 

Additionally, this data is sent by the BE2 to the accounting system 38 on a timed 
rollover event, which happens every 30 minutes or so. Embodiments of the invention allow 
the user to determine the amount of time between timed rollover events. 

10 Near the end of the day, the translator 36 (FIG. 1) generates an End of Day Broadcast. 

This should give all the BE2s within the EGMs 12, 14 on the floor enough time to respond to 
the host before the end of day. An end of day event can be treated like a timed rollover event, 
and the BE2 can send meter data to the accounting system 38. 

In addition, the ABS system can take an end of day "snapshot" of the DG table 

15 records in the DB. Then, daily delta values can be derived from this daily snapshot. 

REPORTING: 

The Slot Accounting application system running on the MGMD server 60 has 
flexibility in its reporting. The number of possible reports is nearly endless, and will grow as 
20 the user realizes the potential of the system. A user interface can assist the user in 
maintaining: sub-game descriptions, game types, configurations and reporting. 

Example reports that can be generated by embodiments of the invention are illustrated 
in FIGs 19-23. Illustrated in FIG. 19 is an example report for an MGMD slot master, which 
The MGMD Slot Master report describes the games by game type. Games with a specific 
25 configuration can be examined within a particular type, such as "poker." 

Illustrated in FIG. 20 is an example report for an MGMD model analysis report, 
which describes the games by configuration ID. This allows an analyst to review how 
different games compare within the specific configurations. For example, an analyst can 
compare how machines configured as configuration ID 1 are performing relative to 
30 configuration ID 2. 

Illustrated in FIG. 21 is an example report for an MGMD machine analysis report, 
which describes the games by asset number and location. This allows an analyst to review 
how different a single game is performing on a daily basis. For example, an analyst can 
compare how machine 20003 is performing as compared to machine 20004. 
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Illustrated in FIG. 22 is an example report for an MGMD machine analysis report, 
which describes games by wager denomination. This allows an analyst to review how 
different single wagering denominations are performing on a daily basis. For instance, an 
analyst can compare how $.25 slots are performing compared to $5.00 slots. 

Illustrated in FIG. 23 is an example report for an MGMD machine analysis report, 
which describes games within a cabinet. This allows an analyst to review how different 
games are performing within a single cabinet. For instance, an analyst can compare how a 
$.25 denomination is performing to $1.00 denomination within a single cabinet. 

Although examples of machines and processes have been described herein, nothing 
prevents embodiments of this invention from working with other types of machines and 
processes. Implementation of the data gathering and reporting system is straightforward in 
light of the above description. As always, implementation details are left to the system 
designer. The specific circuits and procedures used to account for the data collection and 
where to store the collected data may be implemented in any way, with any components, 
although preferred components have been listed herein. Although functions are performed in 
a system including a gaming device and a central accounting system, many of the functions 
can be performed on either the gaming device, or the controller, or some functions performed 
on both the gaming device and the controller, depending on how the system is implemented. 
Inclusion of description or illustration of a function in either the gaming device or the central 
controller is not dispositive that the function is located in or must be performed there. 

Thus, although particular embodiments for a multi-game multi-denomination 
accounting system have been discussed, it is not intended that such specific references be 
considered as limitations upon the scope of this invention. 



Patent Application 



16 



4164-196 



